Pyrmont data

Onwards!

Barnabé Monnot https://twitter.com/barnabemonnot (Robust Incentives Group, Ethereum Foundation)https://github.com/ethereum/rig
2020-11-22

Table of Contents


We look at data between epochs 0 and 815.

Performance of duties

Attester duties

We compare the number of included attestations with the number of expected attestations.

Proposer duties

How many blocks are there in the canonical chain?

Again, the same trough during the roughtime incident.

Correctness of attestations

Target checkpoint

Attestations vouch for some target checkpoint to justify. We can check whether they vouched for the correct one by comparing their target_block_root with the latest known block root as of the start of the attestation epoch (that’s a mouthful). How many individual attestations correctly attest for the target?

How does the correctness evolve over time?

Head of the chain

Attestations must also vote for the correct head of the chain, as returned by the [GHOST fork choice rule]. To check for correctness, one looks at the latest block known as of the attestation slot. Possibly, this block was proposed for the same slot as the attestation att_slot. When the beacon_block_root attribute of the attestation and the latest block root match, the head is correct!

How does the correctness evolve over time?

Aggregate attestations

eth2 is built to scale to tens of thousands of validators. This introduces overhead from message passing (and inclusion) when these validators are asked to vote on the canonical chain. To alleviate the beacon chain, votes (a.k.a. individual attestations) can be aggregated.

In particular, an attestation contains five attributes:

Since we expect validators to broadly agree in times of low latency, we also expect that a lot of individual attestations will share these same five attributes. We can aggregate such a set of individual attestations \(I\) into a single, aggregate, attestation.

When we have \(N\) active validators, about \(N / 32\) are selected to attest for each slot in an epoch. The validators for a slot \(s\) are further divided between a few committees. Identical votes from validators in the same committee can be aggregated. Assume that two aggregate attestations were formed from individual attestations of validators in set \(C(s, c)\), validators in committee \(c\) attesting for slot \(s\). One aggregate contains individual attestations from set \(I \subseteq C(s, c)\) and the other individual attestations from set \(J \subseteq C(s, c)\). We have two cases:

How many individual attestations are contained in aggregates?

We can plot the same, weighing by the size of the validator set in the aggregate, to count how many individual attestations each size of aggregates included.

Overall, we can plot the Lorenz curve of aggregate attestations. This allows us to find out the share of attestations held by the 20% largest aggregates.

The answer is 30%.

How much savings did aggregates provide?

We compare how many individual attestations exist to how many aggregates were included in blocks.

We have 40.58 times more individual attestations than aggregates, meaning that if we were not aggregating, we would have 40.58 as much data on-chain.

In how many aggregate attestations is a single attestation included?

We look at all individual attestations in our dataset, i.e., individual, unaggregated votes, and measure how many times they were included in an aggregate.

Most attestations were included in an aggregate once only

How many redundant aggregate attestations are there?

We call myopic redundant identical aggregate attestations (same five attributes and same set of validator indices) which are included in more than one block. It can happen when a block producer does not see that an aggregate was previously included (e.g., because of latency), or simply when the block producer doesn’t pay attention and greedily adds as many aggregates as they know about.

The mode is 1, which is also the optimal case. A redundant aggregate does not have much purpose apart from bloating the chain.

We could generalise this definition and call redundant an aggregate included in a block for which all of its attesting indices were previously seen in other aggregates. We didn’t compute these as they are much harder to count.

How many times did a block include the exact same aggregate attestation more than once?

We could call these strongly redundant, as this is pure waste.

We see that 9 times, identical aggregates were included twice in the same block.

How many aggregates in a block are included by another aggregate in the same block?

We now define subset aggregates. Suppose two aggregates in the same block with equal attributes (slot, committee index, beacon root, source root and target root) include validator sets \(I\) and \(J\) respectively. If we have \(I \subset J\), i.e., if all validators of the first aggregate are also included in the second aggregate (but the reverse is not true), then we call the first aggregate a subset aggregate of the second.

Subset aggregates, much like redundant aggregate attestations (equal aggregates included in more than one block of the canonical chain), can be removed from the finalised chain without losing any voting information. In fact, subset aggregates use much less local information than redundant aggregates. To root out subset aggregates, a client simply must ensure that no aggregate it is prepared to include in a block is a subset aggregate of another. Meanwhile, to root out redundant aggregates, a client must check all past blocks (until the inclusion limit of 32 slots) to ensure that it is not including a redundant aggregate. In a sense, subset aggregate are “worse” as they should be easier to root out.

So among all included aggregates in blocks, how many are subset aggregates? We count these instances for attestations included in blocks until slot 15000.

We find that 1.04% included aggregates are subset aggregates.

How often are subset aggregates of size 1?

Taking a look at instances of subset aggregates, we often observe that the subset aggregate has size 1. In other words, it is often the case that a “big” aggregate is included, aggregating very many validators, and then a second aggregate of size 1, namely, an individual attestation, is included too, while this second individual attestation is already aggregated by the first, larger aggregate.

Awesome!! Clients are leaving subset aggregates of size 1 out of their blocks. This is the right decision.

How many times were clashing attestations included in blocks?

We look at situations where two aggregate attestations are included in the same block, with identical attributes (same attesting slot, attesting committee, beacon chain head, source block and target block) but different attesting indices and neither one is a subset of the other. We define the following two notions, assuming the two aggregate attestations include attestations of validator sets \(I\) and \(J\) respectively:

Let’s first count how many aggregates are strongly clashing in blocks before slot 15000.

How many are weakly clashing?

None! That’s pretty great. It means blocks always include the most aggregated possible attestations, and we have a local optimum to the aggregation problem.

Aggregates glossary

We’ve looked at aggregate attestations in a few different ways. We offer here a table to summarise the definitions we have introduced and associated statistics.

Name Explanation Statistics Recommendation
Aggregate Attestation summarising the vote of validators in a single committee There are 1778033 aggregates included from slot 0 to slot 26143 x
Individual attestation A single validator vote There are 72148054 individual attestations x
Savings ratio The ratio of individual attestations to aggregate attestations The savings ratio is 40.58 Keep it up!
Redundant aggregate An aggregate containing validator attestations which were all already included on-chain, possibly across several aggregates with different attesting indices x Don’t include these
Myopic redundant aggregate An aggregate included more than once on-chain, always with the same attesting indices There are 1317231 myopic redundant aggregates, 74.08% of all aggregates These are redundant too: don’t include them either

In the next table, we present definitions classifying aggregates when two or more instances are included in the same block with the same five attributes (attesting slot and committee, beacon root, source root and target root).

Name Explanation Statistics Recommendation
Strongly redundant aggregate An aggregate included more than once in the same block There are 9 strongly redundant aggregates Keep only one of the strongly redundant aggregates
Subset aggregate If not strongly redundant, an aggregate fully contained in another aggregate included in the same block There are 11060 subset aggregates until slot 15000, 1.04% of all aggregates until slot 15000 Drop all subset aggregates
Strongly clashing aggregates If not a subset aggregate, an aggregate with attesting indices \(I\) such that there exists another aggregate attesting for the same in the same block with attesting indices \(J\) and \(I \cap J \neq \emptyset\) There are 192711 strongly clashing aggregates until slot 15000, 18.16% of all aggregates until slot 15000 These cannot be aggregated further. Do nothing
Weakly clashing aggregates If not a strongly clashing aggregate, an aggregate with attesting indices \(I\) such that there exists another aggregate attesting for the same in the same block with attesting indices \(J\) There are 0 weakly clashing aggregates until slot 15000, 0% of all aggregates until slot 15000 These can be aggregated further into one aggregate with attesting indices \(I \cup J\). In an ideal world, we have 0 weakly clashing aggregates

Size one aggregates appear often in the dataset.

Name Explanation Statistics Recommendation
Subset aggregate of size 1 A subset aggregate which is an unaggregated individual attestation There are 0 subset aggregates of size 1 until slot 15000, 0% of all subset aggregates until slot 15000 Definitely drop these
Aggregate of size 1 An individual attestations included without being aggregated There are 6717 aggregates of size 1 Either it is weakly clashing, so aggregate it further; or it is a subset aggregate, so drop it; or it is a redundant

Client comparisons

Client distribution

Aggregates included per block

Attestations over time

Epoch 0 to 99

A moment in time, between 2020-11-18 12:00:00 and 2020-11-18 22:40:00.

Epoch 100 to 199

A moment in time, between 2020-11-18 22:40:00 and 2020-11-19 09:20:00.

Epoch 200 to 299

A moment in time, between 2020-11-19 09:20:00 and 2020-11-19 20:00:00.

Epoch 300 to 399

A moment in time, between 2020-11-19 20:00:00 and 2020-11-20 06:40:00.

Epoch 400 to 499

A moment in time, between 2020-11-20 06:40:00 and 2020-11-20 17:20:00.

Epoch 500 to 599

A moment in time, between 2020-11-20 17:20:00 and 2020-11-21 04:00:00.

Epoch 600 to 699

A moment in time, between 2020-11-21 04:00:00 and 2020-11-21 14:40:00.

Epoch 700 to 799

A moment in time, between 2020-11-21 14:40:00 and 2020-11-22 01:20:00.

Epoch 800 to 814

A moment in time, between 2020-11-22 01:20:00 and 2020-11-22 02:56:00.

Subset aggregates

Subset aggregates are aggregates included in a block which are fully covered by another aggregate included in the same block. Namely, when aggregate 1 has attesting indices \(I\) and aggregate 2 has attesting indices \(J\), aggregate 1 is a subset aggregate when \(I \subset J\).